Hey @pramsey!

I've started fixing #513, but I realized that I'm not sure which is the real use case that you want to be tackled. OGR driver only works when you want to download specific formats, such as: kml, csv, shp, etc... When you try to export a kml file of a private table w/o api_key it fails. If you send the request w/ your api_key it works. And if you want to export data from a public table you can request it with and without the master api_key. So far so good, no system tables are involved for public tables when you use the OGR driver.

When I try to send the folowing query w/o api_key (see this tests ^^): SELECT * FROM geometry_columns LIMIT 1 it fails with system tables are forbidden. I understand that this is the use case that raises this issue, doesn't it?

If not, please help to me to understand better this issue. I've implemented a few tests with the examples that I just descibed.

Thanks in advance.

For folks using OGR in a "not CARTO" context, the first thing OGR will do is ask CARTO, "hey, what tables are there?" (this is what happens when an OGRDataSource is instantiated). There's even a super ugly hack in OGR where it tries to sneak a peak at the system tables without letting on to CARTO that it is doing so.

So, running EXPORT CARTO_API_KEY=dfadfa ogrinfo CARTO:pramsey should return to e a list of tables I can read from, for example. Similarly, if I'm using an OGR driver to feed QGIS, when I pop open the layer selector I should see all the layers I have read access to.

Now, as it stands we're not going to re-open access to the pg_* tables, but the geometry_columns view is already a way to get a list of layers that are visible to the current user, so that's not a bad thing to open up.

Anyways, the use case is "given this key, what can I see?" and the apps that use it are things like ogrinfo and any other "select the thing you want" style application. Otherwise you're expecting the user to arrive with an a priori list of things she has access to, which may not be the case.